home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-145 < prev    next >
Text File  |  1988-12-01  |  33KB  |  870 lines

  1.  
  2.  
  3.  
  4.                                                                J. Postel
  5. IEN 145                                                              ISI
  6.                                                              29 May 1980
  7.  
  8.  
  9.  
  10.                Internet Meeting Notes - 14 & 15 May 1980
  11.  
  12.  
  13.  
  14.  
  15. I.  INTRODUCTION
  16.  
  17.    The meeting was held at the Laboratory for Computer Science (LCS) at
  18.    MIT.  Dave Clark was the host.
  19.  
  20. II.  OVERVIEW AND OBJECTIVES
  21.  
  22.    Vint Cerf put forward the problem of internet computer mail as a
  23.    topic that must be addressed in the next few months.  This would be
  24.    an interim system not expected to support multimedia mail but to
  25.    operate on TCP and to provide some mechanism for interworking NCP
  26.    supported mail with TCP supported mail.
  27.  
  28.    Another issue is gateway-host interaction, especially for congestion
  29.    control.
  30.  
  31.    A third topic is routing in a large packet radio environment with
  32.    optional use of backbone point-to-point links.
  33.  
  34. III.  STATUS REPORTS
  35.  
  36.    A.  ARPA
  37.  
  38.       Vint Cerf reported that the IP and TCP specifications (IENs 128
  39.       and 129) are now stamped as DOD standards.  DCEC will serve as the
  40.       focus for coordinating this within DOD.  A seminar for DOD people
  41.       is planned for July at NBS to explain TCP.
  42.  
  43.       The monthly reports are very useful, but still needed are some
  44.       milestone schedules, for planning and cross project coordination.
  45.  
  46.    B.  BBN
  47.  
  48.       Dale McNeill reviewed the work on the VAN gateway, noted the
  49.       arrival of the FAX equipment, described the installation of the
  50.       PSP terminal at TANUM, and noted that improvements have been made
  51.       to the CMCC software.
  52.  
  53.       Mike Brescia described the VAN gateway in more detail.  The
  54.       operation of the gateway is still some way off.  Current activity
  55.  
  56.  
  57. Postel                                                          [Page 1]
  58.  
  59.  
  60.                                                                  IEN 145
  61. Internet Meeting Notes
  62.  
  63.  
  64.  
  65.       focuses on the X.25 interfaces.  At this point there was an
  66.       extended discussion of low level interface options.
  67.  
  68.       Jack Haverty described the work on the Unix IP and TCP.  Most
  69.       recently a version using shared memory for user/TCP communication
  70.       has been tested and is 2 to 3 times faster than the older "pipes"
  71.       version.  Work is just beginning on an IP and TCP for VAX Unix.
  72.       This version will be in the kernel and will include the
  73.       fragmentation and reassembly features.  Also in progress are a TCP
  74.       for a HP 3000, and a TCP-TIP in a 316.  There was also some
  75.       discussion of which versions of Unix are involved:  The VAX Unix
  76.       is version 7, the current 11/70 Unix is version 6.  Jack also
  77.       mentioned some performance measurements using a traffic generator.
  78.       This will be documented in a forthcoming IEN.
  79.  
  80.       Ruth Nelson briefly discussed a local net project at BBN which is
  81.       building a net based on the CHAOS net design.  There is now a
  82.       system with two interfaces which is tested by linking two
  83.       terminals.
  84.  
  85.       Bill Plummer reported on the TENEX/TOPS20 IP and TCP status.  A
  86.       number of improvements have been made to the debugging version at
  87.       BBNF and these should soon be distributed and installed at other
  88.       sites.  Among the improvements are:  a resolution of the "data
  89.       stream capture problem," an update to the internet user queues, an
  90.       improvement to the gateway functions - especially updating the
  91.       gateway table.  Bill has also prepared an "Installation Guide for
  92.       Wizards."
  93.  
  94.       Ginny Strazisar reported that the last ELF based gateway has been
  95.       converted to MOS, and that the first gateway running in an LSI-11
  96.       has been delivered to SRI.  Also a three port gateway is working.
  97.  
  98.    C.  COMSAT
  99.  
  100.       Hoi Chong reported that there are currently a few problems with
  101.       the COMSAT gateway which seem to be related to a power supply.
  102.       Also it was noted that the line to NSRDC will be removed at the
  103.       end of May.  The IP and TCP used in the COMSAT hosts has been
  104.       improved and these programs now support the timestamp option.  The
  105.       FAX machine and protocols are in place and ready to be used, what
  106.       is needed is a common FTP to move the bits to other sites.  COMSAT
  107.       was particularly active in the "Bakeoff" as reported in several
  108.       messages.  Within COMSAT there is an investigation of a local net
  109.       to link some PDP-11 and IBM computers.  Hoi also distributed a
  110.       memo on COMSATs internet activities and milestones.
  111.  
  112.  
  113.  
  114.  
  115. Postel                                                          [Page 2]
  116.  
  117.  
  118.                                                                  IEN 145
  119. Internet Meeting Notes
  120.  
  121.  
  122.  
  123.    D.  DCA
  124.  
  125.       Ed Cain reported that the DCEC gateway had been considerably
  126.       improved with help from Bill Plummer, Dave Mills and others.  Ed
  127.       also reported that DCEC role in the DOD protocol standards will
  128.       have three aspects:  (1) Executive Agent, (2) Review Panel, (3)
  129.       Laboratory.  This Laboratory will be based on the EDN.
  130.  
  131.    E.  DOD
  132.  
  133.       Ray McFarland reported that a group in his office building a TCP
  134.       2.5 for a PDP 11/34 with Unix (v.6).  This group needs software
  135.       for Telnet and Echo processes.  Ray also discussed his role as an
  136.       information coordinator in DOD.  He receives many requests for
  137.       information from within DOD.  He needs help in fielding these
  138.       questions.  In particular more data on performance would be very
  139.       helpful.
  140.  
  141.    F.  ISI
  142.  
  143.       Jon Postel reported that multi-media mail system is being
  144.       redesigned, and that a new draft of the MPM specification is
  145.       available.  Also good progress has been made in the investigation
  146.       of program verification tools for protocol analysis - especially
  147.       AFFIRM.  ISI has ordered 4 computer readable clocks which maintain
  148.       their time by listening to WWVB.  Jon also described the recent
  149.       movement of users between the various machines at ISI.
  150.  
  151.    G.  Linkabit
  152.  
  153.       Estil Hoversten reported that Linkabit is not much involved in the
  154.       internet activities directly, but rather in the details of SATNET
  155.       and the WBC project.  Estil and Danny Cohen are working on an
  156.       overview paper.
  157.  
  158.    H.  LL
  159.  
  160.       Jim Forgie noted that one goal of his project is to demonstrate
  161.       point-to-point speech via the WBCNET in FY 80.  This may be hard
  162.       to do due to the slippage in the schedule for some of the key
  163.       pieces.  Lincoln is going ahead with the development of the voice
  164.       terminals and their access path -- the LEXNET.  In cooperation
  165.       with ISI programs are being written to support NVP2, ST, and IP.
  166.       Lincoln is using the ISI developed EPOS system for this project.
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173. Postel                                                          [Page 3]
  174.  
  175.  
  176.                                                                  IEN 145
  177. Internet Meeting Notes
  178.  
  179.  
  180.  
  181.    I.  MIT
  182.  
  183.       Dave Clark reported on the various systems at MIT and their
  184.       interconnections.  Things are getting quite complex.  (1) Unix:
  185.       MIT has a copy of the IP/TCP from BBN, which MIT modified to have
  186.       a user accessible IP interface.  A TFTP was installed in this
  187.       host.  (2) Multics has had only small changes since last time,
  188.       there is now a Name Server.  (3) The ALTOs now have IP, UDP and
  189.       TFTP in BCPL running; IP, TCP and Telnet (with SUPDUP) in MESA are
  190.       being programmed.
  191.  
  192.       Dave noted that the lack of implementation of fragmentation and
  193.       reassembly is causing problems.
  194.  
  195.       Dave gave some performance measures of the local network at MIT
  196.       (LCSNET v1) which indicate very high reliability and very low
  197.       average load.  However there is some trouble interfacing MIT-XX (a
  198.       TOPS20) to this local net.
  199.  
  200.       Dave noted that version 2 of this network is in hardware testing
  201.       and that the Nu Machine (a personal computer being developed at
  202.       MIT) will interface to the version 2 LCSNET.
  203.  
  204.    J.  MITRE
  205.  
  206.       Anita Skelton reported that starting with a half completed Z8000 C
  207.       cross-compiler obtained from MIT, the compiler was finished, an
  208.       assembler and loader was written.  Then starting with BBN's C
  209.       version of SRI's MOS, the interprocess communication was modified,
  210.       the terminal handler was rewritten, and device drivers were added;
  211.       MOS is running in the Z8000.  MITRE is now converting the MOS-TCP
  212.       to C, rewriting large portions and following the DOD spec.
  213.  
  214.       There are two Z8000 development boards interfaced to the MITRE
  215.       cable, with the cable contention algorithms coded, and packets
  216.       have been exchanged on the cable.  MITRE hopes to have TCP running
  217.       in the Z8000s soon.
  218.  
  219.       The next step is to implement Telnet and interface the 11/70 to
  220.       the Z8000.  The intention is to have a high speed DMA interface to
  221.       the 11/70 via the UMC-Z80 and also a parallel interface via the
  222.       DR11-C, so that comparable measurements with TCP running over the
  223.       cable can be made.  (These measurements for the older interface
  224.       unit have been made).
  225.  
  226.       In addition, a cable bus test bed will be installed at DCA in
  227.       Reston.  The interface units will be Z8000 based and built by
  228.       Reaction Instruments; the interface units will sell for about
  229.  
  230.  
  231. Postel                                                          [Page 4]
  232.  
  233.  
  234.                                                                  IEN 145
  235. Internet Meeting Notes
  236.  
  237.  
  238.  
  239.       $4000 with a parallel host port and two terminal ports
  240.       (asynchronous and synchronous).  The cable will sit between the
  241.       IMP and the NFE, with terminals attached to the cable, and one
  242.       Z8000 unit will act as a gateway.
  243.  
  244.    K.  NDRE
  245.  
  246.       Yngvar Lund reported that NDRE is investigating a local network
  247.       with HDLC interfaces to the connected computers.  The connected
  248.       computers will be built up of modules based on Z80 processors and
  249.       programmed to support voice protocol, HDLC, TCP, etc.
  250.  
  251.    L.  RSRE
  252.  
  253.       Andy Bates noted the work on Extended Memory MOS was reported in
  254.       IEN 136.  IP was recoded in CORAL66 for EMOS and a recoding of TCP
  255.       is planned.  Modems to upgrade the RSRE-UCL line are on order.
  256.       Work is in progress on a gateway between PPSN and PSS.
  257.  
  258.    M.  SRI
  259.  
  260.       Ron Kunzelman gave an overview of SRI's activities and a brief
  261.       rundown on hardware available.  Ron discussed some instrumentation
  262.       efforts underway at SRI.  A PDP 11/44 is on order to aid in this
  263.       work.
  264.  
  265.       Ed Perry discussed some of the problems with the Ft. Bragg
  266.       installation of the Packet Radio net.  The gateway (or attached
  267.       nets) seem to have a low packet/second throughput limit.  This is
  268.       causing the higher level protocols to be modified to use fewer
  269.       packets (e.g., a "half duplex" user mode).
  270.  
  271.       There was some discussion at this point of XNET and again the
  272.       problem of "big" datagrams.  It really is important to have
  273.       fragmentation and reassembly implemented everywhere.
  274.  
  275.       Holly Nelson reported on the port expander.  New versions were
  276.       delivered to Ft. Bragg and UCL.
  277.  
  278.       A new directory has been set up for the current version of TIU
  279.       software.  It is <TIU-SOFTWARE> on SRI-KL.  News of interest to
  280.       TIU programmer or others concerned with MOS software should be
  281.       sent to the MOS-Users-List run by Noel Chiappa.
  282.  
  283.    N.  UCL
  284.  
  285.       Rob Cole related the recent activities at University College.
  286.       There are many pieces of equipment at UCL connected in complicated
  287.  
  288.  
  289. Postel                                                          [Page 5]
  290.  
  291.  
  292.                                                                  IEN 145
  293. Internet Meeting Notes
  294.  
  295.  
  296.  
  297.       ways.  The current focus is a local "Cambridge Ring" network.  The
  298.       NIFTP now works on ISIE and an LSI-11 host.  There is a revised
  299.       specification of NIFTP forthcoming.  UCL has a grant to provide a
  300.       computer mail service between UK and US university users.  There
  301.       is a major concern about cost of transmission via IPSS, so current
  302.       focus is on multi-destination mail in single transmission.
  303.  
  304.       The PDP-9s which serve as a gateway between the ARPANET and EPSS
  305.       will die if either EPSS changes or the 32-bit leaders in the
  306.       ARPANET go away.  The PIXIE device is no longer is use.
  307.  
  308.    O.  UCLA
  309.  
  310.       Bob Braden reported on the IP and TCP in the IBM 3033 at UCLA.
  311.       The operating system is VM with OS-MVT.  The IP and TCP are
  312.       running and the 96-bit leader (24 bit address) support is
  313.       installed.  Further work is needed in the area of "gateway"
  314.       functions in the IP.  In TCP some work is needed in the ACK policy
  315.       area.  One can poke this system via telnet.  Try "NETSTAT" and
  316.       "HELP-TCP".
  317.  
  318.    P.  XEROX
  319.  
  320.       Vint Cerf read the following report sent in by John Shoch:
  321.  
  322.       1.  We have contributed our efforts to measure the effectiveness
  323.       of the Packet Radio Network when used as part of the Pup
  324.       environment.  IEN 138 describes some of the (disappointing)
  325.       results obtained with the new IPRs; we are in the process of
  326.       moving one of the radios, however, and plan to replicate the tests
  327.       in the near future.
  328.  
  329.       2.  IEN 140 is a paper prepared with Danny Cohen and Ed Taft,
  330.       outlining the use of "mutual encapsulation" as a means to support
  331.       the coexistence of the Pup protocols and the IP protocols.
  332.  
  333.       3.  On Tuesday, May 13, Xerox joined with DEC and Intel to
  334.       announce the results of an effort to establish a common
  335.       specification for a local network, based upon the Ethernet
  336.       technology.
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347. Postel                                                          [Page 6]
  348.  
  349.  
  350.                                                                  IEN 145
  351. Internet Meeting Notes
  352.  
  353.  
  354.  
  355. IV.  MEASUREMENTS
  356.  
  357.    Andy Bates reported that RSRE conducted further measurements (since
  358.    the last meeting).  Their findings again indicate a large spread in
  359.    the delay through the concatinated ARPANET and SATNET.  Some
  360.    speculated that the ARPANET introduces this spread.  The RSRE group
  361.    suggest that it would be appropriate to introduce a provision for a
  362.    negotiated retransmission option.  Also a larger window would help.
  363.  
  364.    Rob Cole presented the results of some recent measurements made by
  365.    UCL of the gateway and SATNET.  The gateway at UCL was able to echo
  366.    packets at 34 packets/second.  When the path was extended to the BBN
  367.    gateway, the UCL gateway accepted 14 packets/second, but very few
  368.    echo replies were received from the BBN gateway.  A port expander in
  369.    the path did not pose a limit on either measurement.
  370.  
  371. V.  GATEWAY PROTOCOLS AND HOSTS
  372.  
  373.    Jim Mathis presented his procedure for routing.  The main points are
  374.    first pick any gateway, second refine the chance to the best gateway
  375.    and third detect the failure of that gateway should it occur.
  376.  
  377.       o  Pick a Prime gateway
  378.       o  Poll it at a slow rate
  379.       o  Send to the Prime gateway
  380.       o  Accept and act on a Redirect message
  381.       o  Ping gateway in use if higher level protocol complains
  382.       o  Periodically change the Prime gateway
  383.  
  384.    Does this procedure get unstable in high load?
  385.  
  386.    IENs 109 and 131 should be reviewed by host IP implementors.
  387.  
  388. VI.  TELNET AND FTP FOR TCP
  389.  
  390.    Jon Postel reported on draft specifications for Telnet and FTP for
  391.    TCP.  For Telnet the key changes are that ICP is eliminated and the
  392.    single full duplex connection is between ports U and L.  Another
  393.    change is that the Telnet SYNCH becomes DM + Urgent, but one can't
  394.    count Urgents in the way one used to count Interrupts.
  395.  
  396.    For FTP, again ICP is eliminated for the control connection, which is
  397.    now the full duplex connection between ports U and L.  The major
  398.    change here is the elimination of the BYTE command and all that
  399.    implies.  Other changes affect the defaults for the data connection
  400.    and the "third party" transfers.  The MAIL and MLFL commands are
  401.    included in the specification, and the new reply codes are used.
  402.  
  403.  
  404.  
  405. Postel                                                          [Page 7]
  406.  
  407.  
  408.                                                                  IEN 145
  409. Internet Meeting Notes
  410.  
  411.  
  412.  
  413. VII.  NEW IMPS
  414.  
  415.    Vint Cerf reported that BBN has formed a separate BBN Computer
  416.    Company.  This company sells a C-30 machine (formerly known as an
  417.    MBB).  The current C-30 emulates an H316.
  418.  
  419.    Some things on the queue for IMP improvements are:
  420.  
  421.    1.  extend the memory capacity of the C-30 IMP program
  422.    2.  make software changes to support more than 4 hosts
  423.    3.  provide HDLC interfaces for hosts
  424.    4.  investigate the non blocking interface
  425.    5.  provide logical addressing for hosts
  426.  
  427.    Note also that a TCP-TIP is being developed with the TCP/Telnet code
  428.    in a H316 and the IMP part in a C-30.
  429.  
  430. VIII.  THE CMCC
  431.  
  432.    David Flood Page gave a brief review and a demonstration of the CMCC
  433.    functions.  Basically the CMCC programs collect data from cooperating
  434.    gateways and display the results on a terminal.  The programs reside
  435.    at ISIE  in directory <CMCC>.  The key program is CMCC-DISPLAY.  Some
  436.    files in this directory give helpful information about the program.
  437.    These are:  HELP.TXT, NEWS.TXT, and SESSION.TXT.  Further information
  438.    can be obtained from David via sndmsg to DFloodPage@BBNE.  Please see
  439.    also IEN 131 and 132.  The demo went very well and these programs
  440.    should be useful to any gateway builder.
  441.  
  442. IX.  INTERNET PROTOCOL SPECIFICATIONS
  443.  
  444.    Ken Shotting presented some results of studying the IP specification
  445.    for a formal description.  The key result is the identification of
  446.    ambiguous areas in the specification.  In particular, the interaction
  447.    of the fragmentation procedure and the return route option is one
  448.    cause for concern.  Another issue is the use of the identification
  449.    field.
  450.  
  451. X.  EGG BREAKING
  452.  
  453.    Danny Cohen led a discussion of the problems arising from assumptions
  454.    about which end of a word/page/..., bytes are transmitted from.  This
  455.    is a holy war between the big-endians and the little-endians (see IEN
  456.    137).  Noel Chiappa and Danny were appointed as a small group to
  457.    argue about it.
  458.  
  459.  
  460.  
  461.  
  462.  
  463. Postel                                                          [Page 8]
  464.  
  465.  
  466.                                                                  IEN 145
  467. Internet Meeting Notes
  468.  
  469.  
  470.  
  471. XI.  FLYING PACKET RADIOS
  472.  
  473.    Radia Perlman presented some ideas on how to handle mobile host
  474.    (e.g., flying packet radios) based on having the gateways do most of
  475.    the work.  This approach is based on the gateway using a "link-state"
  476.    routing procedure and a method of handling partitioned nets as if
  477.    each partition were a separate net.  The method presented is related
  478.    to but not identical with that presented in IEN 120.  A revision of
  479.    IEN 120 will be forthcoming.
  480.  
  481.    Carl Sunshine presented an alternate strategy for dealing with mobile
  482.    hosts which makes the hosts do most of the work.  This scheme uses
  483.    the existing IP source routing option and a new GCP message.  It
  484.    calls for a new host (or special functions in an existing host or
  485.    gateway) to support (1) forwarding and (2) a global name server.  New
  486.    messages are needed in the gateway protocol (IEN 109) to relay
  487.    information about a mobile host's current location to the name server
  488.    and the "connected" hosts.  This procedure is described in IEN 135.
  489.    This procedure may also be workable for multihomed hosts and as a
  490.    least effort solution to the partition problem.
  491.  
  492.    Clearly a decision must be made as to whether these problems are to
  493.    be solved within the gateways or not.
  494.  
  495.    Vint Cerf described another routing problem.  This problem arises
  496.    when a destination can be reached either within a network or via
  497.    another network which is connected to the first network in two (or
  498.    more) places.  For example, the ARPANET and the WBCNET will be
  499.    connected in four places.  It may be better for messages from Boston
  500.    to Los Angeles to go one hop in the ARPANET then via WBCNET then one
  501.    hop in the ARPANET, than cross country via many hops in the ARPANET.
  502.    Another example, is a large Packet Radio environment surrounding a
  503.    small ARPANET style network.  Messages from one packet radio to
  504.    another packet radio on the opposite side of the environment might
  505.    best be forwarded through the ARPANET style net rather than via many
  506.    PRNET repeaters.  This out-of-net crossnet routing is a difficult
  507.    decision to make by current procedures.  (The latter example was
  508.    described as a "cloud of packet radios."  First we had a flying PR,
  509.    now we have a whole cloud!  I hope it doesn't rain!!!)
  510.  
  511. XII.  SOURCE ROUTING IN A CAMPUS ENVIRONMENT
  512.  
  513.    Jerry Saltzer presented his ideas on routing in a collection of local
  514.    network in a campus environment.  Much of the strategy is based on
  515.    the lack of central control over the environment.
  516.  
  517.    A Name Server will be provided that will supply route information to
  518.    be used in the source route.  Source routing permits gateways to be
  519.  
  520.  
  521. Postel                                                          [Page 9]
  522.  
  523.  
  524.                                                                  IEN 145
  525. Internet Meeting Notes
  526.  
  527.  
  528.  
  529.    very simple, and allows the end user some control over the route.
  530.    The latter is good for trouble shooting, and performance control.
  531.  
  532.    These ideas are described in IENs 143 and 144 which were distributed
  533.    at the meeting.
  534.  
  535. XIII.  CONGESTION CONTROL
  536.  
  537.    Dave Clark discussed some studies about what to do when a Source
  538.    Quench message arrives.  A simulation program was used to try various
  539.    methods.  All were bad.  The delay in the feedback loop is quite
  540.    large and some information needs to be supplied about how far away
  541.    (in time) the bottleneck is.
  542.  
  543. XIV.  LOGICAL HOST SUPPORT
  544.  
  545.    Jon Postel and Bill Plummer discussed some of the issues in logical
  546.    host support.  The problem came up with a desire to run the testing
  547.    gateway at the same time as the regular IP.  This is not possible but
  548.    points out the need for the IP layer to support the multiple logical
  549.    host concept.
  550.  
  551. XV.  BAKEOFF
  552.  
  553.    The "distributed bakeoff" was too distributed in space and time to be
  554.    as effective as one would like.  Some good things did come from it.
  555.    (E.g. see Dave Mills messages).  It was felt that the next time it
  556.    should be scheduled for one day and with the participants in two or
  557.    three locations.
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579. Postel                                                         [Page 10]
  580.  
  581.  
  582.                                                                  IEN 145
  583. Internet Meeting Notes
  584.  
  585.  
  586.  
  587. XVI.  NEXT MEETING
  588.  
  589.    The next meeting will be held at RSRE in Malvern, England, on 7,8,
  590.    and 9 October 1980.  Attendance will be restricted so if you plan to
  591.    attend please clear that with Vint Cerf and notify Linda.  John Laws
  592.    will be the host and information about the local arrangements will be
  593.    distributed at an early date.  Malvern is about two and one half
  594.    hours by train from London.
  595.  
  596.    AGENDA ITEMS
  597.  
  598.    1.  Resolution of the Partitioned Net Problem - Cerf
  599.  
  600.    2.  Proposal for Controlled Routing - Cohen
  601.  
  602.    3.  Experience with VAN Gateways - Brescia, Kirstein
  603.  
  604.    4.  Demonstration of Interim Internet Mail - Postel
  605.  
  606.    5.  Performance Evaluation Parameters - SRI
  607.  
  608.    6.  Name Server Demonstration - SRI
  609.  
  610.    7.  New ST Document and Explanation - Cohen, Forgie, Hoversten
  611.  
  612.    8.  Tiny Pipe Nets vs. the Catenet - Mills
  613.  
  614.    9.  Congestion Control - Clark
  615.  
  616.    ACTION ITEMS:
  617.  
  618.    1.  XNET Specification - Haverty, Strazisar, Mathis, Tomlinson
  619.  
  620.    2.  Tenex running TCP4 - Plummer
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637. Postel                                                         [Page 11]
  638.  
  639.  
  640.                                                                  IEN 145
  641. Internet Meeting Notes
  642.  
  643.  
  644.  
  645. APPENDICES:  Small Group Discussions
  646.  
  647. A.  FTP and Mail
  648.  
  649.    Need to extend current style of computer mail to work in the
  650.    internet.  The extension of "Mailbox@Host" to "Mailbox@Host@Net" may
  651.    not be acceptable because too many programs must be changed.  Rather
  652.    something like "Mailbox@Place" is suggested.  This gives all hosts at
  653.    least one global name for mail purposes.  (Will there be a name
  654.    czar?)  "Place" is going to have to map to a 32-bit internet address.
  655.    The mailer will have to try to send the mail via TCP if both source
  656.    and destination know that or via NCP if both know that or if one is
  657.    TCP only host and other is a NCP only host via a forwarding host that
  658.    knows both and provides a special forwarding function.
  659.  
  660.    Postel will produce an IEN on this topic.
  661.  
  662. B.  FTP
  663.  
  664.    Brief discussion of FTP and default data ports.  The data ports
  665.    should be U and L-1 so that port pairs are not required in the users
  666.    portspace.  Also it seems OK to use the new reply codes.
  667.  
  668. C.  Measurements
  669.  
  670.    Tools are needed for measurements, for example, echo servers, and
  671.    time stamps.  Echo servers can be TCP based, UDP based, or use the
  672.    GGP; but more are needed.  Timestamp needs and desirable properties
  673.    will be described in a memo by Rob Cole and Andy Bates.  Jack
  674.    Haverty's forthcoming IEN on a traffic generator should help too.  Ed
  675.    Cain has a report on a TCP Tester.  Also note the CMCC facilities.
  676.  
  677. D.  Fault Isolation
  678.  
  679.    This discussion was subtitled "What to do when things go wrong."  The
  680.    conclusion was "try another gateway."
  681.  
  682. E.  Transport Layer Specification
  683.  
  684.    Richard Tenney is working on a task at BBN (under contract from NBS)
  685.    to specify a Transport Protocol.  He is developing a specification
  686.    methodology along the way.  Richard had some questions about the TCP
  687.    specification and the actual behavior of real TCPs.  The main
  688.    questions had to do with out-of-order data, resets, and closing
  689.    cleanly.
  690.  
  691.  
  692.  
  693.  
  694.  
  695. Postel                                                         [Page 12]
  696.  
  697.  
  698.                                                                  IEN 145
  699. Internet Meeting Notes
  700.  
  701.  
  702.  
  703.    Richard noted that we all should look at some NBS reports:
  704.  
  705.       "Draft Features Analysis of Transport Protocols"
  706.  
  707.       "Draft Service Specifications of Transport Protocols"
  708.  
  709.    obtainable from John Heafner of NBS (Heafner@NBS-10).
  710.  
  711. F.  Fragmentation and Reassembly
  712.  
  713.    Fragmentation and Reassembly must be implemented so that datagrams of
  714.    up to 576 octets (including header) may traverse the catenet.  It is
  715.    proposed to hold a special bakeoff to test this capability in early
  716.    September.
  717.  
  718. G.  Gateway-Gateway Protocol
  719.  
  720.    Discussion of how much of this must be known by the hosts.  The
  721.    messages:   Source Quench, Destination (Host/Net) Unreachable,
  722.    Redirect, Echo/Echo Reply.  Much discussion of error reporting should
  723.    it be in GGP or IP?  (The current IP error option seems useless).
  724.    Postel will write a memo on error reporting (including who processes
  725.    which errors).
  726.  
  727. H.  IP Option Overflow
  728.  
  729.    The problem is that some IP header option fields (e.g., return route,
  730.    timestamp) may expand, causing the maximum header size to be
  731.    exceeded.  Ways to handle this might be: (1) discard the packet, (2)
  732.    expandable options should have an "overflowed" flag which gets set
  733.    when they can't grow any more and the packet is forwarded without
  734.    expanding the option, (3) expandable option should be sent with
  735.    filler so header is "right" or max length to start with.  On header
  736.    overflow both source and destination hosts should be told out about
  737.    the error.  The issue was not resolved.  But the problem should be
  738.    discussed in an "Implementers Guide."
  739.  
  740.    An additional problem concerns making full length fragments when
  741.    variable length options are present making it likely that the first
  742.    fragment will overflow the next maximum packet size and have to be
  743.    further fragmented later.  One suggestion is to leave the first
  744.    fragment not quite full in such a case.
  745.  
  746. I.  Name Server
  747.  
  748.    SRI will implement a name server.  It will be an extension of the one
  749.    specified in IEN 116.
  750.  
  751.  
  752.  
  753. Postel                                                         [Page 13]
  754.  
  755.  
  756.                                                                  IEN 145
  757. Internet Meeting Notes
  758.  
  759.  
  760.  
  761. J.  Acknowledgement Algorithms - Adaptive Timeouts
  762.  
  763.    There seems to be a lot of ACK traffic so maybe ACKs should be sent
  764.    on a periodic basis rather than on an event basis.  The
  765.    retransmission strategy also needs to be smarter.  Could it be
  766.    negotiated?  Type of service should be a consideration in these
  767.    algorithms.  Bill Plummer and Andy Bates will conduct an experiment.
  768.    Idea:  set retransmission time according to the Network at the other
  769.    end of the connection.
  770.  
  771. K.  ARPANET Problems
  772.  
  773.    The "8 messages outstanding at a time" problem was discussed.  It
  774.    turns out that the maximum messages in transit can often be less than
  775.    8 due to heavy loads at the destination IMP.  It seems that the only
  776.    solution to this is to provide more buffers and message blocks in the
  777.    busy IMPs.
  778.  
  779. RECENT DOCUMENTS
  780.  
  781.    IEN        Author       Title
  782.    ---        ------       -----
  783.    131        Flood Page   Gateway Monitoring Protocol
  784.    132        Flood Page   The CMCC Terminal Process
  785.    133        Sollins      The TFTP Protocol
  786.    134        Postel       Internet Meeting Notes-4,5, & 6 February 1980
  787.    135        Sunshine     Addressing Mobile Hosts in the ARPA Internet
  788.                            Environment
  789.    136        Wiseman      Memory Management Extensions to the Micro
  790.                            Operation System for PDP-11/23/34/35/40
  791.    137        Cohen        On Holy Wars and a Plea for Peace
  792.    138        Shoch        Initial Comparison of EPRs and IPR in the Pup
  793.                            Internet Environment
  794.    139        Haverty      HOSTs as IMPs
  795.    140        Shoch        Mutual Encapsulation of Internetwork
  796.                            Protocols
  797.    141        Bennett      Message System Issues
  798.    142        Postel       Time Server
  799.  
  800. DOCUMENTS DISTRIBUTED
  801.  
  802.    IEN        Author       Title
  803.    ---        ------       -----
  804.    143        Saltzer      Environment Considerations for Campus-Wide
  805.                            Networks
  806.    144        Saltzer      Source Routing for Campus-Wide Internet
  807.                            Transport
  808.  
  809.  
  810.  
  811. Postel                                                         [Page 14]
  812.  
  813.  
  814.                                                                  IEN 145
  815. Internet Meeting Notes
  816.  
  817.  
  818.  
  819. ATTENDEES
  820.    Vint Cerf                ARPA               Cerf@ISIA
  821.    Mike Brescia             BBN                Brescia@BBNE
  822.    Ross Callon              BBN                RCALLON@BBND
  823.    Len Evenchik             BBN                EVENCHIK@BBNE
  824.    Gil Falk                 BBN
  825.    Jack Haverty             BBN                JHAVERTY@BBND
  826.    Dale McNeill             BBN                DMCNEILL@BBNE
  827.    David Flood Page         BBN                DFLOODPAGE@BBNE
  828.    Ruth Nelson              BBN                RNelson@BBND
  829.    Radia Perlman            BBN                PERLMAN@BBN
  830.    William Plummer          BBN                Plummer@BBNA
  831.    Virginia Strazisar       BBN                STRAZISAR@BBNA
  832.    Hoi Y. Chong             COMSAT             Chong@ISIE
  833.    Chris Elliott            CTEC               CTEC@BBNC
  834.    Ed Cain                  DCEC               Cain@EDN-UNIX
  835.    Jim Showalter            DCEC               gamma@EDN-UNIX
  836.    Michael Begun            DEC                BEGUN@DEC-MARLBORO
  837.    Ray McFarland            DoD                McFARLAND@ISIA
  838.    Ken Shotting             DoD                Shotting@SRI-KL
  839.    Danny Cohen              ISI                Cohen@ISIB
  840.    Jon Postel               ISI                Postel@ISIF
  841.    Carl Sunshine            ISI                Sunshine@ISIF
  842.    Estil Hoversten          Linkabit           Hoversten@ISIA
  843.    Jim Forgie               Lincoln Lab        FORGIE@BBN
  844.    Noel Chiappa             MIT                JNC@MIT-XX
  845.    David Clark              MIT                Clark@MIT-Multics
  846.    Steve Kent               MIT                STK@MIT-XX
  847.    Jerry Saltzer            MIT                Saltzer@MIT-Multics
  848.    Karen Sollins            MIT                Sollins@MIT-XX
  849.    Anita Skelton            MITRE              Anita@MITRE
  850.    Frank Deckelman          NAVELEX            DECKELMAN@ISIA
  851.    Yngvar Lundh             NDRE               Yngvar@SRI-KA
  852.    Oyvind Hvinden           NDRE               Oyvind@SRI-KA
  853.    Glen Allgaier            NOSC               ALLGAIER@ISIC
  854.    Merle Neer               NOSC               Neer@ISIA
  855.    Andrew Bates             RSRE               RSRE-T4@ISIE
  856.    John Laws                RSRE               RSRE-T4@ISIE
  857.    Ron Kunzelman            SRI                Kunzelman@SRI-KL
  858.    Jim Mathis               SRI                Mathis@SRI-KL
  859.    Holly Nelson             SRI                HNelson@SRI-KL
  860.    Ed Perry                 SRI                Perry@SRI-KL
  861.    Robert Cole              UCL                UKSAT@ISIE
  862.    Peter Kirstein           UCL                PKIRSTEIN@ISIA
  863.    Bob Braden               UCLA OAC           Braden@UCLA-CCN
  864.  
  865.  
  866.  
  867.  
  868.  
  869. Postel                                                         [Page 15]
  870.